As handheld computing devices (also referred to herein as personal digital assistants (“PDAs”)) have evolved, the computing capabilities of this class of devices has increased greatly. One hardware component of PDAs in particular that has seen great improvement is the display screen. Over time, both the resolution and pixel density of PDA display screens have been greatly increased. As utilized herein, the term “resolution” refers to the number of horizontal and vertical pixels that are accessible on the display screen. For instance, some PDAs utilize display screens having 240 horizontal pixels and 320 vertical pixels, while other PDAs utilize display screens having 480 horizontal pixels and 640 vertical pixels. As used herein, the term “pixel density” refers to the number of pixels that are accessible on the display screen within a specified unit of measurement. Typically, pixel density is referred to in dots (or pixels) per inch (“dpi”). For instance, some PDAs utilize display screens having 96 dpi, while other PDAs utilize display screens having an improved pixel density of 192 dpi.
The improved resolution and pixel density of modern PDAs has been a boon for users. The improved resolution and pixel density allow more information to be displayed on the screen and therefore allows for easier viewing of documents, Web pages, and for performing other functions. The improved resolution also improves clarity and readability. However, the improved resolution and pixel density has produced challenges for the programmers that write application programs for PDAs. These challenges have generally been caused by the fact that many PDA applications are written to assume that the display screen will have a particular pixel density. This problem is compounded by the fact that the operating system-provided application programming interfaces (“APIs”) that application programs call to perform screen-related functions often take pixels as parameters. So, for example, if an application configured for use with a 96 dpi display screen draws an on-screen user interface button that is one-half inch wide, it would call an API to create a button that is 48 pixels in width. However, if the same application program is executed on a PDA with improved pixel density, 192 dpi for instance, the same 48 pixel wide button would only be one-quarter inch wide. Because application programs created prior to the introduction of devices having improved pixel density are unaware of the increased density, all of the user interface objects drawn by these programs will be displayed smaller than intended. Input operations where the screen is utilized as a touch sensitive device may also be misunderstood by such legacy application programs.
One solution to this problem is to require application programmers to re-program their applications to support the improved pixel density of newer PDAs. This, however, can be frustrating and time consuming for the programmer that has to actually re-code the application. This can also be frustrating for users that must wait until the application has been re-coded to use the application with a new device having increased pixel density. In some cases, a programmer may simply decide not to re-code the application program for the higher density displays. Users of the program would then be forced to migrate to another program in order to take advantage of higher density display screens.
Another solution to this problem is to create a new set of APIs for performing screen-related functions on higher resolution screens. This solution, however, is also undesirable because it does not allow legacy applications to utilize the higher density displays and also requires that programmers creating new high density-aware applications utilize an entirely new API. It is therefore desirable for legacy applications to be able to input and output correctly to an improved pixel density screen without rewriting the applications, to allow new high density-aware applications to use the same set of APIs for screen operations as legacy applications, and to enable this functionality without rewriting the APIs that perform screen input and output. It is with respect to these considerations and others that the various embodiments of the present invention have been made.